Distributed software systems that operate over an open network, particularly a Wide Area Network such as the Internet, often have the need for secure communications over the network and authentication between system elements to prevent spoofing and other security breaches. Various protocols have been used to provide such security. Exemplary protocols include the Secure Sockets Layer or SSL, Transport Layer Security or TLS, Secure-HTTP, and IP Security or IPSEC.
Instrumental in these protocols are cryptographic mechanisms. Two primary cryptographic mechanisms are secret key and public key cryptography. Secret key is a type of symmetric encryption in which both parties know and use the same or shared secret key to encrypt and decrypt communications. Encryption algorithms, or ciphers, based on the secret key, mathematically transform or encrypt the plain text in the message into cipher text. The same key and algorithm are used by the other party to decrypt the cipher text. Public key cryptography is a type of asymmetric encryption that uses pairs of different keys, one for encryption and one for decryption. One of the keys or private key is kept secret by a party and the other key or public key is provided freely to other parties. When plain text is converted into ciphertext or encrypted using the private key, it may be converted back into plain text only using the public key and vice versa. The Rivest-Shamir-Adleman or RSA algorithm is one of the most widely used public key algorithms.
The SSL protocol uses the Public Key Infrastructure or PKI, a form of public key cryptography, to secure communications over otherwise unsecured networks. RSA, together with the X.509 standard for digital certificates, form the basis of PKI. A certificate 200 according to the X.509 standard is shown in FIG. 2. The standard portion 202 of X.509 includes the version 204 (which indicates the particular version of the X.509 standard), serial number 208 (which is assigned by the certificate authority and uniquely identifies the certificate), signature algorithm 212 (which identifies the algorithm used to generate the digital signature), issuer or signer 216 of the certificate (which identifies the certificate authority that issued the certificate), period of validity 220 for the certificate (which identifies both the earliest and latest times that the certificate is valid), the subject or owner 224 of the public key, and the public key 228 of the owner of the certificate. Extensions 232 provide a location for issuers to add their own private information to the certificate. It can include authority and subject key identifiers, key usage, private key usage period, and a list of permitted use and restrictions on usage for the certificate. The certificate 200 further includes the digital signature field 236 (encrypted using the private key of an issuing entity). The digital signature field is deduced based on the signature algorithm identifier 212, and created by a secure hash of the other fields in the certificate and an encryption of that hash using the issuer's private key. When a certificate has been issued and signed by the same entity, that certificate is known as a self-signed certificate or a root certificate. In a certificate chain or chain of trust, a root certificate is always at the top of the chain and is used to validate each of the other lower certificates in the chain. A trusted third-party, such as Verisign™, that issues digital certificates is known as a Certificate Authority or CA. As can be seen from the foregoing, to implement PKI each system element in the distributed network requires a unique digital certificate and associated private key.
Providing each system element with a unique certificate can be achieved by secure communications between the system element and a certificate authority. In this approach, the system element generates a public/private key set and makes a certificate request to the certificate authority. Secure distribution of the private key is not an issue because no distribution is needed (the private key is generated on the target system element and not required as input by any other system).
In service-oriented customer environments, it is often desirable to create an island of trust to allow certain trusted consumers of the service to obtain access to special rights and privileges. The island of trust must not only be difficult to compromise by third parties but also, in many applications, by administrators of customers. For example, a service may wish to allow only certain trusted consumers of the service to obtain access to discounted or free licenses or rights to use specified software. The service consumer must somehow be authenticated, and the mechanism used to authenticate the consumer must not be something that an administrator can use to take advantage of the discounted licenses for other applications or other consumers.
In most applications, existing authentication protocols cannot provide an island of trust. Such systems do permit authentication of services and service consumers; however, the same system cannot be used to identify whether or not a consumer is entitled to a special right or privilege or the administrator could identify any application as trusted to obtain the right or privilege. The authentication mechanism needs to be controlled completely by the publisher of the service.
While secret handshakes can be employed, they can fail to provide a robust solution. A secret handshake refers to the client and server sharing an algorithm for hashing or the like. The client, by successfully indicating knowledge of the handshake algorithm, establishes to the server that the client can be trusted. However, if the algorithm is compromised a new handshake algorithm must be devised, and all clients and servers must be updated with the new algorithm.